Network devices may periodically transmit an alarm to an entity monitoring the status of the network device. An alarm is a notification that an undesirable condition or event has occurred or is occurring at the network device. For example, an alarm may be raised if the network bandwidth available to a device falls below a specified level, or if a device on the computer network experiences a specified condition, e.g., the utilization of a processor on the device is over 90%. Alarms may be initiated using a variety of techniques, e.g. an alarm for a network device may be initiated by the device itself or by another entity.
A variety of components may monitor alarms issued by a network device. For example, a network management station (hereinafter a NMS) is a network element that allows an administrator to monitor the status of network devices operationally connected to the NMS. An administrator may view all the alarms that are received by the NMS from network devices monitored by the NMS.
In another example, a managed service provider (hereinafter a MSP) may also monitor alarms issued by network devices. A MSP is an entity, usually a business, which manages one or more computer networks that are each used by other entities (usually customers of the MSP). MSPs are advantageous when a small business desires to outsource the management of its own computer network to the MSP. In order to effectively manage one or more computer networks for each of its customers, a MSP requires an accurate view of its customer's computer networks. The MSP may monitor alarms raised by network devices of each of the one or more computer networks that the MSP manages to monitor the status of the one or more computer networks.
Entities that monitor alarms raised by network devices may receive a large number of alarms. It is incumbent upon the administrator to sort through all the alarms received at the monitoring entity to determine which of the alarms is most important, i.e., which alarm should be addressed next. To alleviate the burden on the administrator, some entities that monitor alarms may apply a set of rules to the received alarms to give greater weight to those alarms originating from a named network device or associated with a named problem. For example, alarms that issue from a particular email server that must remain operative or any alarm that is associated with an aborted process on a network device may be flagged to bring these alarms to the attention of the administrator.
However, this approach is problematic in that it requires that the administrator determine, a priori, what network devices or problems require the monitoring entity to process alarms associated with those network devices or problems in a special manner to give the alarms greater weight. If a particular network device or problem is not captured in a rule applied by the monitoring entity, then the monitoring entity cannot distinguish how important is an alarm associated with that particular network device or problem. As a result, an administrator implementing this approach must supply a set of detailed rules to the monitoring entity, which may not accurately reflect the current business conditions or operational status of the network. Consequently, some alarms may be given more weight than they should, while other alarms that should be addressed immediately go unnoticed by the administrator.
Accordingly, there is an unaddressed need in the art for determining the order in which alarms issued by network components should be addressed, while avoiding the problems and difficulties associated with the current state of the art. The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.